6.4. E-mail Address Policies
You need to keep a couple of
issues to keep in mind when it comes to e-mail address policies. In
Exchange Server 2003, e-mail address policies could be created, but not
immediately applied, although this was not desired behavior. In Exchange
Server 2010, e-mail address policies are applied synchronously anytime
you write recipient objects in Exchange Server 2010, including mailbox
moves from Exchange Server 2003 to Exchange Server 2010. What this
means is that you may have a number of mailboxes that have been
configured with new e-mail proxy addresses or even a different primary
SMTP address because the mailbox has been moved; this can lead to
confusion and increased support calls. To avoid this, you should
evaluate your e-mail address policies prior to implementing mailbox
moves to Exchange Server 2010. In the case of mailboxes whose e-mail
addresses you don't want to change, clear the Automatically Update
E-Mail Addresses Based On E-Mail Address Policy check box on those mailboxes through the ADUC Exchange Server 2003 snap-in as shown in Figure 4 before the mailbox is moved to Exchange Server 2010.
A second issue to be
considered with respect to e-mail address policies is whether any SMTP
address spaces in your Exchange Server 2003 organization are ambiguously
non-authoritative—that is, the address space has been marked
authoritative in one policy but non-authoritative in another. Any SMTP
address spaces configured in this way should be resolved before you run
Exchange Server 2010 PrepareAD
in your environment to avoid potential mail flow interruptions. This
issue and its effects, along with the recommended preventative measurer.
6.5. Moving Mailboxes from Exchange Server 2003 to Exchange Server 2010
Mailboxes are moved to Exchange Server 2010 using the Move Request cmdlets or the Exchange Server 2010 Exchange Management Console; mailbox
moves cannot be performed using the Exchange Server 2003 Exchange
System Manager (ESM). In addition, the Exchange Server 2003 Mailbox
server must be Exchange Server 2003 SP2.
In Exchange Server 2003, mailbox
moves were synchronous; this meant that if the ESM console was closed
before the move completed, the mailbox move was cancelled. Additionally,
all of the mailbox's data was moved through the ESM instance performing
the move, so if the move was initiated on an administrative computer
other than the source and destination mailbox server, all data flowed
through the administrative computer rather than from source to
destination mailbox server.
In Exchange Server 2010, mailbox moves are now asynchronous and initiated with move requests. The new Move Request cmdlets perform an asynchronous move because they send a request to the Microsoft
Exchange Mailbox Replication Service (MRS), a service running on all
Exchange Server 2010 Client Access servers in your organization; the
mailbox move itself is performed by the MRS. The MRS enables you to
manage mailbox
moves from anywhere within the organization after the move request is
placed, and the console or script initiating it does not need to remain
open during the move.
In summary, the new move request functionality in Exchange Server 2010 has the following the benefits:
Mailbox moves are asynchronous and are carried out by the MRS.
Mailboxes
are kept online during asynchronous moves (Exchange Server 2007 SP2 or
Exchange Server 2010 to Exchange Server 2010 only).
The mailbox's Recoverable Items are moved with the mailbox (Exchange Server 2010 to Exchange Server 2010 only).
As
soon as the mailbox begins to move, content indexing starts to scan the
mailbox so that fast searching is available upon completion of the
move.
Throttling can be configured for each MRS instance, each mailbox database, or each mailbox server.
Move requests can be initiated between forests; these are referred to as remote move requests.
Mailbox moves can be managed from anywhere within the organization.
Mailbox data content does not travel through an administrative computer.
The move history of the mailbox is preserved in the mailbox.
Nicolai Wagner
System Manager, Exchange Operations, Axel Springer AG, Germany
We are currently
migrating from Exchange Server 2003 to Exchange Server 2010 using
Outlook 2003 for clients, and we have found the following factors need
to be considered when determining which mailboxes should be moved at the
same time when migrating to Exchange Server 2010 in order to reduce
user impact:
When moving mailboxes
to Exchange Server 2010, any delegates should be moved at the same
time—for example, managers and their administrative assistants—as a user
in Exchange Server 2010 can manage calendars on Exchange Server 2003,
but not vice versa. When the mailbox of a delegate is on Exchange Server
2003 and the mailbox they are accessing is on Exchange Server 2010, the
manager's calendar appears to be empty when the delegate opens it with
Outlook 2003 or OWA. An administrative assistant that is based on
Exchange 2003 can only open one additional calendar; when trying to open
more calendars, Outlook 2003 shows an error message.
We also determined
that conference rooms should be moved early in the upgrade to Exchange
Server 2010, prior to moving users who book or otherwise manage the
conference rooms. Otherwise, users booking the conference rooms are able
to book the Exchange Server 2003 conference room mailbox as an attendee
but not as a resource. Resolving this requires moving the conference
room mailbox to Exchange Server 2010, and then converting the mailbox to
a room mailbox using theSet-Mailbox cmdlet with the Type parameter—for example, Set-Mailbox <MailboxID> -Type Room.
